ניהול העלות בפרויקט תוכנה ניהול פרויקטי תוכנה

Size: px

Start display at page:

Download "ניהול העלות בפרויקט תוכנה ניהול פרויקטי תוכנה"

Lenard Hopkins
5 years ago
Views:

1 Ch. 7 פרק 7 ניהול העלות בפרויקט תוכנה

2 ניהול עלות בפרויקט עלות הפרויקט מתייחסת להוצאות הכספיות שעל הפרויקט להוציא על מנת להביא להשלמתו ולהשגת יעדיו בפרויקטי תוכנה העלות העיקרית היא שכר העבודה ניהול עלות בפרויקט Project Cost Management תחום הידע העוסק בתהליכים ובפעילויות שבאמצעותם אומדים, מתקצבים ומבקרים עלויות, ושמאפשרים להשלים את הפרויקט במסגרת התקציב שאושר תהליכי ניהול עלות בפרויקט 1. אמידת עלויות. 3 בקרת עלויות מעקב ובקרה תכנון סגירה ייזום 2. קביעת תקציב ביצוע 2 ניהול העלות בפרויקט תוכנה

3 ניהול עלות בפרויקט: אמידת עלויות 1. אמידת עלויות. 3 בקרת עלויות מעקב ובקרה תכנון סגירה ייזום 2. קביעת תקציב ביצוע תשומות תפוקות אומדני עלות לפעילויות תוכנית בסיסית לתכולה בסיס האומדן לו"ז של פרויקט עדכון מסמכי הפרויקט תוכנית משאבי אנוש רשימת הסיכונים גורמים סביבתיים של הארגון נכסי תהליכים ארגוניים 3 ניהול העלות בפרויקט תוכנה

אמידת עלויות אמידת עלויות הוא התהליך בו מכינים קירוב של המשאבים הכספיים שנחוצים כדי להשלים את פעילויות הפרויקט אומדני עלות הם תחזיות המבוססות על המידע הידוע בנקודת זמן נתונה אמידת העלות מתחשבת

4 אמידת עלויות אמידת עלויות הוא התהליך בו מכינים קירוב של המשאבים הכספיים שנחוצים כדי להשלים את פעילויות הפרויקט אומדני עלות הם תחזיות המבוססות על המידע הידוע בנקודת זמן נתונה אמידת העלות מתחשבת בסיכונים ובניתוח חלופות יצור לעומת רכישה (make/buy) רכישה לעומת שכירה שימוש במשאבים משותפים שימוש חוזר (reuse) לעומת פיתוח חדש מרכיבי עלות אופייניים עבודה חומרים ציוד שירותים מתקנים אינפלציה עלויות שעת חירום אומדני העלות נעשים מדויקים יותר ככל שמתקדם הפרויקט, ולכן דורשים ליטוש ועדכון במהלך הפרויקט 4 ניהול העלות בפרויקט תוכנה

5 משפך אי-הודאות Uncertainty) *(Cone of סטיית הערכת העלות באבני דרך מקובלות בפרויקט תוכנה * Steve McConnell, Software Estimation, Microsoft Press, ניהול העלות בפרויקט תוכנה

6 ענן אי הודאות של האומדן הענן מתאר את טווח אי-ההתכנסות של משפך אי-הודאות במהלך הפרויקט כאשר הפרויקט אינו מנוהל היטב ומצב ההתקדמות )תכולה, מאמץ, לו"ז( אינו ברור לא ניתן לשפר את האומדנים ואי-הודאות נשארת גדולה 6 ניהול העלות בפרויקט תוכנה

7 אילוץ ההתכנסות של משפך אי-הודאות משפך אי הודאות אינו מתכנס מעצמו יש לנקוט בפעולות יזומות לגרום להתכנסותו פעולות אלה כוללות הכנת תוצרים המגדירים את תכולת הפרויקט ובכך מאפשרים אומדנים מדויקים יותר 7 ניהול העלות בפרויקט תוכנה

8 אומדן עלות של פרויקט תוכנה בפרויקטי תוכנה רבים נעשים האומדנים במונחי מאמץ, אבל... מחיר price עלות cost + רווח + תקורה אומדן עלויות צריך להתחיל מאומדן הגודל / ההיקף = מאמץ effort X רכש + תעריף = גודל / היקף size / scope פריון X =??? שעות עבודה $ $ 8 ניהול העלות בפרויקט תוכנה

9 אומדן גודל / היקף הפרויקט היקף פרויקט תוכנה ניתן לביטוי ככמות של מאפיינים שונים, כגון features סיפורי-לקוח "נקודות סיפור" points) (story דרישות Use Cases Function Points דפי אינטרנט )... מרכיבי GUI )חלונות, דיאלוגים, דוחות, טבלאות בסיסי-נתונים ממשקים מחלקות פונקציות / שגרות שורות קוד 9 ניהול העלות בפרויקט תוכנה

10 אומדנים מקובלים האומדנים המקובלים ביותר עבור גודל LOC = Lines Of Code מדד קלסי לגודל התוכנה KLOC = Kilo (1000) Lines Of Code NFP = Number of Function Points )היקף, אומדן הפונקציונאלית המוגדרת עבור מערכת התוכנה ניתן להמיר בין LOC מדד הגודל משמש כגורם ל- NFP נירמול למדדים אחרים למשל: מספר באגים ל- KLOC או ל- NFP נפח( התוכנה 10 ניהול העלות בפרויקט תוכנה

11 שורות קוד - (LOC) Lines of Code #include <stdio.h> int main(void) { printf("hello World"); return 0; } C COBOL IDENTIFICATION DIVISION PROGRAM-ID. HELLOWORLD * ENVIRONMENT DIVISION CONFIGURATION SECTION SOURCE-COMPUTER. RM-COBOL OBJECT-COMPUTER. RM-COBOL DATA DIVISION FILE SECTION PROCEDURE DIVISION MAIN-LOGIC SECTION BEGIN DISPLAY " " LINE 1 POSITION 1 ERASE EOS DISPLAY "Hello world!" LINE 15 POSITION STOP RUN MAIN-LOGIC-EXIT EXIT. קשיים באומדן ומדידה של שורות קוד הקוד הוא רק חלק קטן מהמאמץ הכולל של פיתוח תוכנה שפות שונות מספר שונה של שורות לא ברור מה בדיוק צריך לספור פקודות? הצהרות והגדרות נתונים? הערות? הוראות בקרה? שורות ששונו / נמחקו? לא כל מה שנכתב מסופק עם המוצר המספר המדויק ידוע רק כאשר המוצר הסתיים אומדן המבוסס על שורות קוד הוא עם סיכון כפול: תהליך האמידה מתחיל באומדן המוצר הסופי אומדן העלות מבוסס על אומדן הגודל הערכה לא-ודאית המבוססת על נתונים לא-ודאיים 11 ניהול העלות בפרויקט תוכנה

12 Function Points (FP)* מרכיבים של היישום הדורשים מימוש של פונקציות עיבוד פונקציונליות Transaction Function - קלט חיצוני )EI( External Inputs פלט חיצוני )EO( External Outputs שאילתות חיצוניות )EQ( External Inquiries Data Function - סוגי FP פונקציות מידע קבצים לוגיים פנימיים )ILF( Internal Logical Files קבצי ממשקים חיצוניים )EIF( External Interface Files ממציא השיטה: (1979) Albrecht A.J. השיטה מעוגנת כיום בתקן ISO ומתוחזקת ע"י קבוצת משתמשים IFPUG User domain External Input External Output External Inquiry Internal Logical File Application domain External Input External Output External Inquiry External Interface File External domain השיטה הומצאה עבור מערכות מידע קיימות התאמות של השיטה לסוגים שונים של מערכות ניתן ליישם את השיטה בהקשר של UML ותכנות מונחה עצמים * ממציא השיטה: IBM, 1979 A.J. Albrecht, 12 ניהול העלות בפרויקט תוכנה

13 שלב א' זיהוי וסיווג פונקציות סוג פונקציה משמעות קלט הנכנס אל תוך גבולות היישום ומפעיל עיבוד או עדכון של קובץ לוגי פנימי פלט היוצא אל מחוץ לגבולות היישום שילוב קלט/פלט )תגובה מיידית( דוגמאות בחירה מתפריט טופס נתונים Alt+Ctl+Del שליחת הודעה הפקת דו"ח העברת קובץ מחיקת פיסקה ממסמך הפעלה/עצירה של סרט מענה לשיחה נכנסת פרטים אישיים של משתמש מקבץ נתונים )לאו דווקא בקובץ/ DB נפרד( מסמך הנערך ע"י המשתמש מנקודת ראות המשתמש או גורם חיצוני רישום כניסות לאתר אחר External Input (EI) External Output (EO) External Inquiry (EQ) Internal Logical File (ILF) קובץ נתוני בדיקות מסך להצגת פרסומות פאנל חיווי של מערכת אזעקה מקבץ נתונים חיצוני המשמש את היישום לקריאה/כתיבה External Interface File (EIF) 13 ניהול העלות בפרויקט תוכנה

14 :Albrecht s Example מערכת לבקרת מלאי J.A.Roberts הינה חברה המוכרת באמצעות מוקד טלפוני 200 סוגים של פריטי ציוד אלקטרוני. לצורך כך נדרשת לחברה מערכת ממוחשבת לניהול המלאי, אשר תהיה בעלת היכולות הבאות: לאפשר למפעיל להזין מספר לקוח קיים או פרטי לקוח חדש )עד 100 לבדוק את דירוג האשראי של לקוחות ודחיית אלה בעלי דירוג נמוך לאפשר למפעיל להזין את הסחורות המוזמנות לבדוק את זמינות הסחורות המוזמנות אם יש מלאי מספיק יש לספק את כל הסחורה לקוחות( אם אין מלאי מספיק יש לספק את המלאי הקיים וליצור הזמנה שתסופק כאשר יהיה שוב מלאי להציג פרטי מלאי, הזמנות ולקוחות לעדכן את רמות המלאי על בסיס אספקות לעדכן את פרטי חשבונות הלקוחות על בסיס תשלומים להפיק תעודת משלוח וחשבונית 14 ניהול העלות בפרויקט תוכנה

15 זיהוי וסיווג של פונקציות Albrecht s Example קלט חיצוני )EI( פלט חיצוני (EO) מספר לקוח פרטי לקוח חדש פרטי הזמנה פרטי אספקה פרטי תשלום לקוח בחירה מתפריט ראשי דירוג אשראי חשבונית תעודת משלוח פרטי לקוח פרטי הזמנה פרטי מלאי שאיתות חיצוניות (EQ) קבצים לוגיים פנימיים (ILF) בקשת פרטי לקוח בקשת פרטי הזמנה בקשת פרטי מלאי קובץ תנועות של סחורה קובץ לקוחות קובץ סחורות קובץ תנועות של לקוחות ניהול העלות בפרויקט תוכנה

16 שלב ב' - חישוב ערכים משוקללים איך קובעים זאת? Complexity = Low average High # of EI # of EO # of EQ # of ILF # of EIF x x x x x = = = = = Total EI + Total EO + Total EQ + Total ILF + Total EIF Unadjusted Function Points - UFP 16 ניהול העלות בפרויקט תוכנה

17 קביעת רמת הסיבוכיות מספר הקבצים המתעדכנים בעקבות קלט/שאילתות External Input Complexity (EI,EQ) # of Data Element Types (DET) # of File Types Referenced (FTR) < > Low Low Average 2 Low Average High >2 Average High High External Output Complexity (EO,EQ) # of Data Element Types (DET) # of File Types Referenced (FTR) < > Low Low Average 2-3 Low Average High >3 Average High High מספר הסוגים השונים של נתונים מספר הקבצים שיש לעדכן באמצעות קלט/שאילתות מספר הסוגים השונים של רשומות בקבצים File Interface Complexity (ILF,EIF) # of Data Element Types (DET) # of Record Element Types (RET) >50 1 Low Low Average 2-5 Low Average High >5 Average High High 17 ניהול העלות בפרויקט תוכנה

18 חישוב מספר FP גולמי Albrecht s Example Complexity = Low average High # of EI = 6 # of EO = 6 # of EQ = 3 # of ILF = 4 # of EIF = 0 x x x x x = = = = = Total EI = 18 + Total EO = 24 + Total EQ = 9 + Total ILF = 28 + Total EIF = 0 Unadjusted Function Points (UFP) = ניהול העלות בפרויקט תוכנה

19 תיקון על פי הערכת הסיבוכיות היחסית של היישום Relative Complexity Adjustment Factor (RCAF) No Subject Grade 1 Requirement for reliable backup and recovery Requirement for data communication Extent of distributed processing Performance requirements Expected operational environment Extent of online data entries Extent of multi-screen or multi-operation online data input Extent of online updating of master files Extent of complex inputs, outputs, online queries and files Extent of complex data processing Extent that currently developed code can be designed for reuse Extent of conversion and installation included in the design Extent of multiple installations in an organization and variety of customer organizations Extent of change and focus on ease of use RCAF = Total 31 NFP = UFP x ) x RCAF( = 70 x ( ) = 70 x 0.96 = ניהול העלות בפרויקט תוכנה

20 היחס בין FP לשורות קוד 1 Function Point = 320 basic assembly language statements 213 macro assembler statements 128 C statements 107 COBOL statements 107 FORTRAN statements 80 PL/I statements 71 Ada 83 statements 64 C++ statements 54 Ada Visual BASIC 16 PowerBuilder 13 SQL 22 Smalltalk statements 20 ניהול העלות בפרויקט תוכנה

21 FP משמשים לאומדן של מדדים אחרים NFP 1.15 NFP 1.2 NFP 1.25 NFP 0.4 approximate page counts for paper documents associated with a software project approximate number of test cases created approximate defect potential for new software projects NFP/150 approximate development schedule in calendar months approximate number of personnel required for the application NFP/750 approximate number of maintenance personnel required to keep the application updated 21 ניהול העלות בפרויקט תוכנה

22 כמה דוגמאות מהחיים...* Application NFP SLOC U.S. Air Traffic Control 306,324 65,349,222 Israeli air defense system 300,655 24,052,367 Iran's air defense system 260,100 23,780,557 Microsoft XP 126,788 8,114,400 American Express billing 20,141 1,432,238 Skype 21,202 1,130,759 Amazon web site 18, ,126 All-in-one printer 1, ,893 Bank ATM controls 3, ,484 Digital camera controls 1,285 82,243 Motorola cell phone 1,507 80,347 JAVA compiler 1,185 63,186 Nintendo Game Boy DS 1,002 53,455 LogiTech cordless mouse ,267 ILOVEYOU computer worm 22 2,838 MYDOOM computer virus 8 1,045 * Capers Jones, A NEW BUSINESS MODEL FOR FUNCTION POINT METRICS, May ניהול העלות בפרויקט תוכנה

23 מאומדן גודל לאומדן מאמץ COnstructive COst MOdel = COCOMO B. Boehm, 1984 מורכב מ- 3 מודלים מודל לאומדן המוצר השלם מודל ביניים intermediate COCOMO מודל לאומדן המוצר למרכיביו המפורטים נתמקד ב- intermediate COCOMO 23 ניהול העלות בפרויקט תוכנה

24 Intermediate COCOMO נתון אומדן גודל המוצר המאמץ הנומינלי S( ב( KLOC- Organic mode )E חודשי אדם( מחושב כפונקציה של אופן הפיתוח פרוייקט תוכנה קטן ופשוט צוות מיומן ומנוסה דרישות מוגדרות Semi-detached mode פרויקט בינוני )גודל צוות מעורב מבחינת וסיבוכיות( נסיון דרישות שחלקן מוגדרות היטב וחלקן פחות Embedded mode אילוצים קשיחים של חומרה, תוכנה ותפעול את המספר הגולמי E יש לכייל לפי מספר מקדמי עלויות E = 2.4xS 1.05 E = 3.0xS 1.12 E = 2.8xS 1.20 (Cost Drivers) 24 ניהול העלות בפרויקט תוכנה

25 Intermediate COCOMO cost drivers 25 ניהול העלות בפרויקט תוכנה

26 - דוגמה Intermediate COCOMO תוכנת עיבוד תקשורת מבוססת מיקרו-פרוססור אמינות גבוהה דרישות ביצועים דרישות לו"ז דרישות ממשקים אופן הפיתוח embedded הערכת גודל 10,000 שורות קוד KLOC) 10) חישוב המאמץ הנומינלי: = x(10) E = חודשי אדם מקדמי עלויות drivers) (cost ראה להלן 26 ניהול העלות בפרויקט תוכנה

המאמץ המשוקלל Intermediate COCOMO חודשי אדם = 59

27 המאמץ המשוקלל Intermediate COCOMO חודשי אדם = E = 1.35 x P i = ניהול העלות בפרויקט תוכנה

28 - מסקנות Intermediate COCOMO אומדן המאמץ של הפרוייקט )59 ח"א( יכול לשמש כקלט לחישוב פרמטרים נוספים עלות כספית הערכת לו"ז התפלגות השלבים והפעילויות עלות המחשבים עלות אחזקה שנתית ועוד... המודל יושם בהצלחה במספר רחב של פרוייקטים אומדן על פי המודל נמצא מדוייק עד כדי 20% בכ- 70% מהמקרים המודל המדוייק ביותר לתקופתו )סוף שנות ה- 80 ( 28 ניהול העלות בפרויקט תוכנה

29 COCOMO II הרחבה של המודל המקורי 1995 מאפשר התייחסות לנושאים נוספים Object orientation Modern life-cycle models Rapid prototyping Fourth-generation languages COTS software COCOMO II הינו מודל מסובך ומורכב בהרבה מהקודם 29 ניהול העלות בפרויקט תוכנה

30 COCOMO II )המשך( שלושה מודלים נפרדים Application Composition Early design Post-architecture אותה נוסחה בסיסית: E = as b b מחושב על בסיס של 5 גורמים: PREC חדשנות: ניסיון קודם של הארגון במוצרים דומים FLEX גמישות: עד כמה הדרישות הן קשיחות. RESL רמת הסיכונים TEAM כישורי הצוות )CMM בשלות התהליכים )על פי מודל PMAT a הוא מכפלה של 17 כופלי עלות מחשבון COCOMO II ברשת: 30 ניהול העלות בפרויקט תוכנה

31 Dr. Amir Tomer Agile COCOMO II מחשבון אינטרנטי המאפשר לכייל הערכה שנעשתה על פי פרויקט קודם ע"פ הבדלי המאפיינים בין הפרויקט הקודם לפרויקט החדש 31 ניהול העלות בפרויקט תוכנה

32 ניהול עלות בפרויקט: קביעת תקציב 1. אמידת עלויות. 3 בקרת עלויות מעקב ובקרה תכנון סגירה ייזום 2. קביעת תקציב ביצוע תשומות תפוקות תוכנית בסיסית לביצועי עלות דרישות למימון הפרויקט עדכונים למסמכי הפרויקט אומדני עלות פעילות בסיס אומדנים תוכנית בסיסית של התכולה לו"ז הפרויקט לוחות שנה למשאבים חוזים נכסי תהליכים ארגוניים 32 ניהול העלות בפרויקט תוכנה

33 קביעת תקציב קביעת תקציב הוא התהליך בו צוברים את אומדני העלויות של פעילויות נפרדות או של חבילות עבודה ויוצרים תכנית בסיסית מאושרת לעלויות קביעת התקציב מתבססת על התשומות הבאות אומדני עלות פעילות בסיס אומדנים )בכל חבילת עבודה( )הנחות ששימשו כבסיס לאומדני העלויות( תכנית בסיסית לתכולה )WBS( לו"ז הפרויקט לוחות שנה למשאבים חוזים נכסי תהליכים ארגוניים )למשל הנחיות אגף הכספים להכנת תקציב( לצורך קביעת התקציב משתמשים בטכניקות הבאות ריכוז עלויות (Cost Aggregation) ניתוח עתודות (Reserve Analysis) חוות דעת מומחים יחסים היסטוריים התאמת מגבלות המימון )קשרים שנמצאו בעבר בין מאפיין לבין גורמי עלות( )תיאום בין הכנסות להוצאות( 33 ניהול העלות בפרויקט תוכנה

34 תוכנית בסיסית לביצוע העלות Baseline) (Cost Performance תוכנית הבסיס לביצועי העלות מסתמכת על התקציב שאושר להשלמת הפרויקט 3500 BAC = Budget at Completion 3000 דרישות מימון בסיס ביצוע העלות הוצאות ניהול העלות בפרויקט תוכנה

35 ניהול עלות בפרויקט: בקרת עלויות 1. אמידת עלויות. 3 בקרת עלויות מעקב ובקרה תכנון סגירה ייזום 2. קביעת תקציב ביצוע תשומות תוכנית ניהול הפרויקט תפוקות מדדי ביצועי העבודה תחזיות לתקציב דרישות למימון הפרויקט מידע על ביצוע העבודה עדכונים לנכסי תהליכים ארגוניים בקשות לשינוי עדכונים לתוכנית ניהול הפרויקט עדכונים למסמכי הפרויקט נכסי תהליכים ארגוניים 35 ניהול העלות בפרויקט תוכנה

36 בקרת עלויות בקרת עלויות הוא התהליך בו עוקבים אחר מצב הפרויקט כדי לעדכן את תקציב הפרויקט וכדי לנהל שינויים בתוכנית הבסיסית לעלויות בעת בקרת עלויות בפרויקט משפיעים על הגורמים שמחוללים שינויים בתוכנית הבסיסית לעלויות מבטיחים שאת כל דרישות השינויים מבצעים בזמן הנכון מנהלים את השינויים בפועל בזמן שהם מתרחשים מבטיחים שבכל תקופה עלות ההוצאות לא גדולה מעלות המימון שאישרו ומבטיחים גם שעלות ההוצאות בכלל הפרויקט לא עולה על המימון שאישרו עוקבים אחר ביצועי העלות כדי לבודד ולהבין את הסטיות מהתוכנית הבסיסית המאושרת לעלויות עוקבים אחר ביצוע העבודה ביחס להוצאות הכספים מונעים משינויים שלא אושרו להיכלל בעלויות המדווחות או בניצול המשאבים מדווחים לכל בעלי העניין המתאימים על שינויים שאישרו ועל העלויות הקשורות בהם פועלים כדי שהחריגות הצפויות מהעלויות יהיו בגבולות מתקבלים על הדעת 36 ניהול העלות בפרויקט תוכנה

37 (Earned Value Management) בקרת עלויות בשיטת "ניהול ערך מזוכה" ניהול ערך מזוכה מתכנן ועוקב אחר שלושה ממדים עבור כל חבילת עבודה וסעיף בקרה ערך מתוכנן (Planned Value = PV) התקציב שאישרו ושהקצו עבור עבודה שיש להשלים על פעילות או מרכיב של מבנה תכולת העבודה סך כל הערך המתוכנן נקרא "תקציב בסיום" BAC) (Budget at Completion = ערך מזוכה (Earned Value = EV) ערך העבודה שבוצעה על פעילות או מרכיב של מבנה תכולת העבודה )במונחי התקציב( הערך המזוכה הנמדד מתייחס לתכנית הביצועים הבסיסית EV לא יכול להיות גדול מתקציב הערך המתוכנן המאושר עבור מרכיב כלשהו )מדוע?( עלות בפועל AC) (Actual Cost = סך העלות שנגרמה ונרשמה כשהשלימו עבודה על פעילות או מרכיב של מבנה תכולת העבודה סך העלות שנגרמה כשהשלימו את העבודה שהערך המזוכה מדד לעלות בפועל אין גבול עליון המדידה כוללת את כל העלות שנגרמה כדי להשיג את הערך המזוכה 37 ניהול העלות בפרויקט תוכנה

38 ערכים מצטברים Dr. Amir Tomer (AC) (PV) ערך מזוכה,(EV) ערך מתוכנן ועלות בפועל כמה עלתה העבודה שבוצעה עד היום תקציב בסיום BAC = Budget At Completion עלות בפועל AC = Actual Cost מה "שווי" העבודה שתוכננה להתבצע עד היום כמה "שווה" העבודה שבוצעה עד היום ערך מזוכה EV = Earned Value זמן נקודת הבקרה 38 ניהול העלות בפרויקט תוכנה

39 ערכים מצטברים Dr. Amir Tomer סטיות מהתוכנית ומדדי ביצוע סטיית לו"ז (Schedule Variance = SV) ההפרש בין הערך המזוכה לבין הערך המתוכנן SV = EV PV סטיית עלות CV) (Cost Variance = ההפרש בין הערך המזוכה לבין העלות בפועל CV = EV AC מדד ביצוע לו"ז (Schedule Performance Index) ההתקדמות שהושגה, יחסית להתקדמות המתוכננת SPI = EV/PV < 1 SPI : הפרויקט בפיגור לו"ז > 1 SPI : הפרויקט בהקדמת לו"ז מדד ביצוע עלות (Cost Performance Index) ערך העבודה שהושלמה יחסית לעלות שנגרמה בפועל )יעילות העבודה( CPI = EV/AC < 1 CPI : הפרויקט גירעוני > 1 CPI : הפרויקט חסכוני זמן SV PV AC EV CV BAC נקודת הבקרה כל המדדים ניתנים הן לחישוב נקודתי )עבור חבילת עבודה נתונה( והן לחישוב מצטבר )מתחילת הפרויקט( 39 ניהול העלות בפרויקט תוכנה

40 ניהול ערך מזוכה דוגמה PV פעילות )היום( מצב הפעילות EV AC 5,000 הפעילות הסתיימה 6,000 5, ,000 הפעילות הסתיימה 1,850 2,000 2 פעילות של 8,000 שעות, הסתיים "בערך חצי" 3,500 4,500 4,000 3 פעילות של 10,000 שעות התחילה לאחרונה 2,350 1,500 2,000 4 סה"כ 12,850 מה מצב הפרויקט? 13,850 13, ניהול העלות בפרויקט תוכנה

41 חישוב סטיות PV פעילות )היום( סטיות מהתוכנית EV AC CV = - 1,000 SV = 0 5,000 6,000 5,000 1 CV = SV = 0 2,000 1,850 2,000 2 CV = - 1,000 SV = ,500 4,500 4,000 3 CV = SV = ,350 1,500 2,000 4 CV = - 1,000 SV = ,850 13,850 סה"כ 13, ניהול העלות בפרויקט תוכנה

42 חישוב מדדי ביצוע PV פעילות )היום( סטיות מהתוכנית EV AC CPI =.82 SPI = 1.0 5,000 6,000 5,000 1 CPI = 1.08 SPI = 1.0 2,000 1,850 2,000 2 CPI =.77 SPI =.87 3,500 4,500 4,000 3 CPI = 1.56 SPI = ,350 1,500 2,000 4 CPI =.92 SPI =.98 12,850 13,850 סה"כ 13, ניהול העלות בפרויקט תוכנה

43 חיזוי על בסיס הנתונים המצטברים לנקודת בקרה נתונה ניתן לחזות את אומדן הפרויקט ביום שיושלם: Estimate at Completion = EAC אומדן העבודה שנותרה עד להשלמת הפרויקט: Estimation to Complete = ETC ניתן לחשב זאת על בסיס הנחות שונות לגבי ההמשך, כדלהלן: Estimation at Completion EAC = Bottom-up ETC + AC EAC = AC + ETC EAC = BAC / Cumulative CPI EAC = AC + ETC Estimation to Complete Bottom-up ETC אומדן )מחדש( של כל הפעילויות שטרם הושלמו וסיכומן bottom-up ETC = BAC - EV ETC = EAC - AC ETC = (BAC EV) / (cumulative CPI x cumulative SPI) הנחת הבסיס אמידה מחדש של העבודה שנותרה הפרויקט "יעלה על הפסים" ויתנהל כמתוכנן מרגע זה ועד להשלמתו הפרויקט ימשיך במגמת הגירעון/החיסכון הנוכחית )על פי מדד ביצוע העלות המצטבר( הפרויקט ימשך בשתי מגמותיו: פיגור/הקדמה )על פי מדד ביצוע הלו"ז המצטבר( וגירעון/חיסכון )על פי מדד ביצוע העלות המצטבר( 43 ניהול העלות בפרויקט תוכנה

44 מדד ביצוע עד להשלמה TCPI) (To-Complete Performance Index = מדד זה חוזה מהם ביצועי העלות שיש להשיג בעבודה שנותרה, רוצים לעמוד ביעד ניהולי מסוים אם עמידה בתקציב המקורי להשלמה BAC היחס בין העבודה שנותרה לבין שארית התקציב המקורי TCPI = (BAC EV) / (BAC AC) עמידה באומדן ההשלמה של הפרויקט EAC היחס בין העבודה שנותרה לבין התקציב שנותר לפי האומדן החדש TCPI = (BAC EV) / (EAC AC) 44 ניהול העלות בפרויקט תוכנה

45 ניהול העלות בפרויקט תוכנה

ניהול העלות בפרויקט תוכנה ניהול פרויקטי תוכנה

Ch. 7 פרק 7 ניהול העלות בפרויקט תוכנה ניהול עלות בפרויקט עלות הפרויקט מתייחסת להוצאות הכספיות שעל הפרויקט להוציא על מנת להביא להשלמתו ולהשגת יעדיו בפרויקטי תוכנה העלות העיקרית היא שכר העבודה ניהול עלות